In a Session Initiation Protocol (SIP) system, as part of the call setup procedure, there are typically two ways that calls can be connected. In a first procedure, the system can respond to a SIP INVITE with a SIP 200 OK message. The SIP 200 OK message indicates that the SIP INVITE was successful and the call is setup. In a second procedure, the system can respond to a SIP INVITE with a SIP 183 Session in Progress Message (or another SIP Provisional Response message). The SIP 183 Session in Progress message allows extra information to be sent while the call is still being setup. In cases where the SIP 183 Session in Progress message is sent, the call is still in a provisional state and is not considered fully setup under the SIP protocol. After the SIP 183 Session in Progress message is sent, a SIP 200 OK message will be sent when the call is fully setup.
The procedure of always of sending a SIP 200 OK message in response to a SIP INVITE works fine in countries where billing begins when the initial call is being setup. However, some countries require that billing for a calling party can only begin when the calling party is connected to a human. In these countries, connection to non-human entities, such as, an Interactive Voice Response (IVR) system requires sending the SIP 183 Session in Progress Message instead of the SIP 200 OK message. When the calling party is eventually connected to a human, the SIP 200 OK message is sent to indicate that the calling party has been connected to a human. A service provider can then use the SIP 183 Session in Progress message and the SIP 200 OK message to provide proper billing.
The model of sending the SIP 183 Session in Progress message when the call is being connected to a non-human entity can cause reliability issues. When the SIP 183 Session in Progress message is sent, the call is considered under SIP rules, not fully setup. If a failure occurs, such as a proxy supporting the call fails, the call is not able to fail over to a second proxy because the call is still in a provisional state. This results in the call being dropped. What is needed is a solution that allows the provisional call to not be dropped when there is a failure prior to the call being fully setup.